Shareware Overload Trio 2/Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO/dir24/nosinst.zip/TUTORETC.ZIP/IP_TUTOR.TXT

Text File | 1993-12-13 | 18KB | 424 lines

What happens when I "TELNET BOB"?

A guide to configuring Packet Radio TCP/IP
by Andrew Benham, G8FSL

This may be freely copied and distributed for non-commercial
use.



The purpose of this guide is to shorten the learning process
when trying to configure a Packet Radio version of TCP/IP.
Most packages come with documentation: this usually goes into
great detail about the syntax of each command. This is fine
provided you know which command you need at the time. If you
don't then you have to wade through pages of text.

Until now, that is...


1. Introduction.

TCP/IP is the name applied to a whole suite of network
protocols, used all over the world on a variety of different
computer setups (commercial, military, academic, etc). TCP and
IP are in fact two protocols from this suite- probably the two
most common and most important protocols. The term "TCP/IP" is
used to refer to the whole caboodle, "TCP" or "IP" on their
own will mean something different.
At this point most documents will ramble on about ISO OSI 7
layer models, peer to peer protocols, etc. Not this one!


2. Physical Links

The TCP/IP network protocols allow computers to be
interconnected and thus networked. The protocols are designed
to allow inter-networking ("IP" stands for Internet Protocol),
and so there is no assumption made about the physical type of
the network.
This means that the TCP/IP traffic has to be moved from one
computer to another by some physical means: TCP/IP doesn't
care HOW this is done (it has to know how to read from and
write to this physical entity, but that's the limit of its
required knowledge).
In the world of wired networks the physical link is often
Ethernet- a 10 Megabit/second data link carried on coax. On
packet radio the physical link is "ordinary" packet radio-
AX25.
In almost every case of a physical link (SLIP, for example, is
an exception), there will be some form of addressing needed in
order to identify the sender and recepient of each message to
the physical link. For example, a message on an AX25 link HAS
to have the callsign of the sender and (unless it's a "CQ"
type message) it has to have the callsign of the recipient.
These addresses (callsigns) are nothing to do with TCP/IP-
they are solely there to move the TCP/IP information about.
Because it can get confusing, if an identifier is in UPPER
CASE in this document then it will be a physical link address
(and since I'm only considering radio links, they're
callsigns).
(SLIP - Serial Link IP - is a protocol for connecting two
machines directly with a serial link between them. This needs
no physical addressing, as it's a direct point-to-point link).


3. Hostnames and IP Addresses

TCP/IP information leaves one machine and arrives at another
(how it gets there physically is not of great interest to
TCP/IP). The machines themselves have to be identified
uniquely in order that information can be sent to the right
one. The identifier used is the "IP Address". The allocation
of these is co-ordinated internationally to ensure no
duplication.
The address is a 32-bit binary number, which allows for about
4000 million different addresses. As the human brain finds
difficulty with those sorts of numbers, the address is usually
broken down into 4 8-bit binary numbers. In binary, 8 bits can
represent a number from 0 to 255. The 4 8-bit numbers are
written down separated by dots, like so:
                         44.131.19.45
The world IP address allocator has reserved the first number
of 44 for the amateur packet radio "organisation" (am p r org,
hence ".ampr.org", see later). The worldwide amateur packet
radio co-ordinator has reserved the second number 131 for the
UK. The UK co-ordinatot (G6PWY) has reserved the third number
19 for RSGB Region 19 (Greater London north of the Thames, and
Hertfordshire). The Region 19 co-ordinator (G8FSL) has
reserved the fourth number 45 for himself. 44.131.19.45
uniquely identifies G8FSL's TCP/IP computer in the world.
Now the IP protocol (excuse the tautology) uses this number to
identify the machine, but the average user can't work with
this as an identifier. Humans prefer names (Bill, Jim, Fifi-
Trixiebell) instead, so usually give each machine a unique
hostname for their use. These hostnames identify the machine
and the organisation in which they are. In the commercial
world these machines usually have snappy names, like
"maple.bnr.co.uk" for a machine codenamed "maple" at a U.K.
company called "BNR". Naturally amateurs use their callsigns
for everything (including passwords! (?)), so use hostnames
like "g8fsl.ampr.org".
It is important to realise that TCP/IP makes (almost) no use
of hostnames - in general, when a hostname is seen it is
looked up in a DOMAIN file to translate it to an IP address
(SMTP - the mail protocol - is an exception to this). This
DOMAIN file may be on the same machine, or it may be on a
remote computer which provides a domain server function. This
DOMAIN file is important - without it all references to
machines would have to be by their IP address.
To try and stop confusion between callsigns (I'm using UPPER
CASE for them, remember) I'll refer to hostnames in full (e.g.
g8fsl.ampr.org).


4. Routing

Networks are all about routing. Without routes, there is no
network. In TCP/IP there are two types of route to consider:
TCP/IP routing, and physical link routing. Two types to
consider, two types to get confused about.
TCP/IP routing is all about passing TCP/IP traffic to a
machine. TCP/IP machines can handle traffic for any other
TCP/IP machine, provided the routes are set up. Again it isn't
important (to TCP/IP) *how* it gets to a machine - that's up
to the physical link.
Physical link routing is concerned with getting AX25 packets
to and from other stations.
The physical link must exist, i.e. you must be able to connect
to the other station, and it is your direct responsibility.
The TCP/IP link is a more abstract concept. No, abstract's not
the right word, so let's try an example.

Alf, G9ALF, has a packet link to Jim, G9JIM, and another to
Bob, G9BOB. He can digipeat (if he must!) through G9DIG to
Tom, G9TOM. That's it, no more links. Therefore his physical
link routing table can only include these 3 entries, and they
are cast in stone.
He can only connect to three stations, so packet radio used to
be dull. But now they're all on TCP/IP these stations provide
him with the physical links to carry his TCP/IP traffic all
over the world. These 3 neighbouring stations are his gateways
to the rest of the world.


4.1 Physical routing

Taking the example above, assuming everybody's TCP/IP
callsigns end in "-5", Alf would have a physical routing table
built like this:

ax25 route add G9JIM-5
ax25 route add G9BOB-5
ax25 route add G9TOM-5 via G9DIG

Watch this last one- depending on the flavour of NOS in use
the "via" word may or may not be needed. "ax route" will
usually display the current entries to make sure NOS and you
agree about the routes.
I've assumed that G9DIG doesn't run TCP/IP, so isn't "G9DIG-
5". If he is running TCP/IP, why is Alf using him as a
digipeater (see later).
One other variable to throw in for consideration- the type of
the physical link.
TCP/IP is a robust networking system, and so it can cope with
packets getting lost - it will send retries. So, of course,
can AX25 (the physical link), but AX25 can also be operated in
a non-retrying mode. Is it better to have TCP/IP handle lost
packets, or for AX25 to do it?
There are pros and cons for the two options. If AX25 handles
the lost packets as well as TCP/IP (the so called "virtual
circuit"), then the link will be more reliable, but it will be
slower and clog up the frequency (there are more packets
flying about). If AX25 operates without handling the lost
packets (in "datagram" mode) there will be fewer packets on
the channel, but the link may not be so reliable.
In general, if the path is good use a "datagram" connection,
but if the path is poor a "virtual circuit" is more likely to
give better results. It boils down to how likely is that that
a packet will be lost?
The link type can be set, both a "default" type and a type for
each individual link. The commands vary, try "mode", "ax25
route mode", or look in the book!


4.2 TCP/IP routing

TCP/IP routing is totally separate from Physical Link routing.
It deals solely with machines, asking "I have traffic for
machine 'xyz', which machine should I send it too?". Sounds
like a crazy question - send it to 'xyz'!
But what if 'xyz' is on the other side of the world? There's
no way that it can be reached directly. Remember though that
any machine can handle traffic for any other, so it is a case
of routing traffic to the most suitable machine in range.

Going back to our example, all the TCP/IP stations have the
logical hostnames we'd expect. Alf, who's only got one port (a
TNC) called 'tnc0', starts to set up his routing table:

route add g9jim.ampr.org tnc0
route add g9bob.ampr.org tnc0
route add g9tom.ampr.org tnc0

Right, they're the obvious routes. Now for the rest of the
world.
Jim is well sited to get to smart_alec.ampr.org, who is a real
TCP/IP whizz-kid, and will route anything anywhere. But Bob is
in a better direction to handle traffic for Suffolk and Essex
(and beyond), and Tom has a brilliant path into Kent (and
beyond).
So Alf wants to use these stations as gateways, to handle his
TCP/IP traffic for him, and wants to add into his routing
table something like:

route add {anyone in Suffolk} tnc0 g9bob.ampr.org
route add {anyone in Essex}   tnc0 g9bob.ampr.org
route add {anyone in Kent}    tnc0 g9tom.ampr.org
route add default             tnc0 g9jim.ampr.org

Unfortunately Alf's version of NOS throws a wobbly with the
first three lines. There must be a way to do it?

Yes, there is!

Let's go back a few pages to IP Addresses. They are 32 bit
binary numbers, usually grouped in 4 lots of 8 bits each (e.g.
44.131.19.45).
Any address in the UK will be 44.131.xxx.yyy in format. 'xxx'
specifies the RSGB region, 'yyy' the user in that region. So
Alf looks in his callbook, and sees that Essex and Suffolk are
in region 16 (as is Norfolk, which is fine as Alf's traffic
for Norlfolk ought to go through Suffolk). Kent is in region
8, together with West and East Sussex- again, traffic for the
two Sussex counties ought to be routed via Kent).

So Alf needs to replace "{anyone in Suffolk}" and "{anyone in
Essex}" by something like:
"anyone whose IP address is '44.131.16.xxx', where it doesn't
matter what the 'xxx' is".
Similarly, the Kent entry needs to be:
"anyone whose IP address is '44.131.8.yyy', where it doesn't
matter what the 'yyy' is".

Saying '44.131.16.xxx' is equivalent to saying "A 32 bit IP
address, where the first 8 bits must represent the decimal
number 44, the second 8 bits 131, the third 8 bits 16, and
anything for the last 8 bits". In other words, anything that
matches "44.131.16.0" for the first 24 bits. And NOS provides
a way to enter that into the routing table, so Alf can add

route add 44.131.16.0/24 tnc0 g9bob.ampr.org
route add 44.131.8.0/24  tnc0 g9tom.ampr.org

for RSGB Regions 16 and 8 respectively.
The slash ("/") tells NOS how many bits out of the 32
(starting "from the left") have to match a given IP address.
For a normal address entry (with no slash), the full 32 bits
must match.
The special "route add default" entry means "any address" (0
bits need match).
NOS is intelligent, in that it picks out of the routing table
the entry that matches the greatest number of bits in the
given address.

NOTE: in Southern England, even as I type (2 September 1992),
we're trying to start an experiment where IP addresses specify
geographical location with better resolution than RSGB Region.
This means that the routing split of IP addresses uses more
than the 24 bits of the above example. If you're happy with
binary numbers you can work it out for yourself, if you're not
a binary guru then this isn't the time or place to learn!

(Most versions of NOS will work without having to type
".ampr.org" after every hostname).


5. Whoops!

Right, all clear so far? What do you mean, as mud?

Well, there's something I've left out!
You know quite well that "g9bob.ampr.org" is the hostname of
the TCP/IP station at G9BOB, who uses the callsign G9BOB-5 for
his TCP/IP setup.
Unfortunately NOS doesn't! But it has a way to find out:
"Address Resolution Protocol" - ARP.
ARP is used to associate an IP address (and thus, via the
DOMAIN file, a hostname) with a physical link protocol and
address, just so TCP/IP can be carried on the physical link to
the right place.
There is an ARP table in NOS, which can either be loaded
either manually, or automatically by NOS asking "on air".
Manually entering the details of your neighbours seems like a
good idea. Alf enters:

arp add g9bob.ampr.org AX25 G9BOB-5
arp add g9tom.ampr.org AX25 G9TOM-5
arp add g9jim.ampr.org AX25 G9JIM-5

If there isn't an entry for a hostname when NOS comes to try a
direct connection, it will put out an "ARP REQUEST". This is a
broadcast on the channel, and says "Hi there, I'm
g9alf.ampr.org, you can connect to me physically as G9ALF-5:
I'm looking for <hostname>, are you there? If you are, send me
your physical address".
If the host hears the "ARP REQUEST", it ought to send an "ARP
REPLY" to the requester, giving the physical address.
If the host is local this transaction will take place, and an
entry made in the ARP table. This entry is only valid for a
certain time, whereas manual entries last for ever: hence it
is better to add the details of your neighbours manually.


6. What happens when I "TELNET BOB"

Hey, that was the title of something I started to read months
ago!
Right, you should now be able to visualise what happens when
Alf types "telnet g9bob" on his computer.

a.   the hostname (which is really "g9bob.ampr.org") gets
     looked-up in the DOMAIN file. If it isn't found an error
     message is given ("host g9bob not found"), and NOS goes
     no further. If it is found, the IP address is returned.

b.   The IP address is run through the TCP/IP routing table,
     and the "best match" route found. (The TCP/IP routing
     table uses only IP addresses, but NOS will probably show
     the table entries with hostnames to make it easy for
     you). This operation cannot fail- it will return the port
     to use, and an IP address to route to (which may be a
     gateway, perhaps the "default" route, or a direct route).
     TCP/IP is still regarding the route as being to
     "g9bob.ampr.org", but is looking for the first stage in
     the route. I'll call the IP address it's going to route
     via "the gateway".

c.   TCP/IP has gone as far as it can. It now needs a physical
     link to carry its traffic to the gateway. It looks-up the
     gateway (in this example "g9bob.ampr.org") in the ARP
     table.
     If there is an entry (well, there is in this case) it
     returns the physical link protocol to use (AX25) and a
     physical link address (G9BOB-5).
     If there wasn't an entry, ARP would broadcast a request
     to try and find the details. At this point it knows the
     port to use (returned from the TCP/IP routing table), and
     the "attach" command will have associated a physical link
     protocol with that port. Thus the broadcast isn't that
     "broad". Fortunately.

d.   We've now left TCP/IP behind, and are in the old world of
     physical links. In practice, we're resolving AX25 links
     to see if digipeaters are involved. This is achieved by
     checking the AX25 routing table, which also gives the
     type of AX25 link (virtual circuit or datagram) to use.

e.   Everything is resolved, and the traffic goes out.

f.   At the far end, G9BOB's machine gets an "incoming Telnet
     session". TCP/IP has to send an acknowledgement to
     "g9alf.ampr.org". Well, in fact TCP/IP doesn't know about
     the hostname, just the IP address of the source of the
     traffic. G9BOB's machine doesn't have to do step (a)
     above, but it does *all* the other steps.
     It is important to realise that TCP/IP does not receive
     any information of how the traffic to it arrived- each
     machine uses its own routing information (I think WNOS is
     an exception to this rule though- it seems to modify its
     routing tables according to received traffic). This is a
     feature of TCP/IP networking, and one which can cause
     problems of comprehension to new users. Most packet radio
     applications use symmetrical routes: TCP/IP need not, and
     if the destination doesn't have a route back then you're
     stuck.


7. Why no mention of NET/ROM ?

It is possible to use NET/ROM physical links to carry TCP/IP
traffic. In this case there is a NET/ROM routing table (in the
same way as an AX25 routing table).
However there is little point in using NET/ROM links if there
are sufficient TCP/IP stations to perform the routing at the
TCP/IP level. In fact, NET/ROM links add more bytes to each
TCP/IP packet and therefore increase channel congestion. And
that's before the NET/ROM has broadcast details of every other
NET/ROM station it can reach, possibly via 6 hops.

So, if you don't need to NET/ROM, don't. It's only something
else to set up.




All trade marks acknowledged.


Andrew Benham   G8FSL       2 September 1992

G8FSL@GB3XP              [e-mail] [44.131.19.195]

==============================================================

This may be freely copied and distributed for non-commercial
use.

Despite being freely copyable, if you feel so inclined,
sending a couple of quid to:

The National Asthma Campaign, Providence House, Providence Place,
  London N1 0NT

would be a suitable expression of thanks.

This document may not be included in a publication (e.g.
newsletter, magazine), or distributed or copied for financial
gain, or used commercially, without prior consulation with the
author.
(Permission will always be given in reality, just that it
might cost you a fiver to the N.A.C.)